IBIS Macromodel Task Group Meeting date: 09 April 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Bob noted that list of attendee names was due for periodic maintenance and removal of those who had not participated recently. Randy noted that it's typical to remove the names of people who have not actively participated in over a year. Curtis took the AR to cull the list and have Bob review the changes. (done - reflected in the Members list above). - Arpad noted that a vote on the DC_Offset BIRD (BIRD197) had been postponed at the last Open Forum meeting. The Open Forum recommended that ATM review it in light of some feedback including grammatical changes. Arpad noted that he had forgotten to add it to the agenda email, but we could discuss it. ------------- Review of ARs: - Mike L. and Bob to produce a revised draft response to the BIRD198 authors. - In progress. Arpad noted that the reason for this AR was that no update had been sent that fully reflected the comments and suggestions from the March 26th meeting. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 02 meeting. Mike L. moved to approve the minutes. Radek seconded the motion. There were no objections. ------------- New Discussion: BIRD197.2 (DC_Offset) Arpad shared BIRD197.2 and noted several grammatical changes he and others had reported. He reviewed corrections with the group and made the changes in a new draft: - 4 instances of "singled ended" ---> "single ended". (Arpad) - 1 instance of "single-ended" ---> "single ended" for consistency. (Randy) - In the Definition of the Issue: section, "The forces all AMI..." ---> "This forces all AMI..." (Arpad) Bob noted that he thought there had also been technical comments. Radek noted that Michael M. had also mentioned that "step response" was used for the first time in the following sentence and not defined in the spec.: "If the impulse response was generated by differentiating the step response..." But Radek noted that he thought the sentence was okay. Arpad said he had responded to Michael's original email because he hadn't understood Michael's comment. Michael's comment had asked about step response being a legal input to the AMI model now, but this particular sentence did not imply that. Curtis said he thought the people from whom Michael had gathered feedback may have been confused and thought the model was now going to generate the IR from the step response. The group agreed that no change was required for this sentence at this time. Ambrish asked to confirm that "shall" means "must" in the following sentence: "The waveform output of the Rx AMI_GetWave shall be adjusted so that the EDA tool can add DC_Offset..." Arpad and the group agreed it does (it does in IBIS in general). Radek objected to the use of "single ended voltage..." and said voltage is voltage. Randy suggested we discuss improvements to the language now so as not to further delay the BIRD. Arpad said the section in question is attempting to define DC_Offset. Radek said DC_Offset is an offset to move the waveform from a single ended port to something that can be handled with differential infrastructure. Radek proposed that the following sentence in the Definition of the Issue: "This forces all AMI simulations to be centered around the mid-level of the single ended signal." be changed to: "This forces all AMI simulations to be centered around the mid-level of the signal of a single ended port." Similar changes were made in several locations. Bob noted that we should add an entry to the Background Information section stating the reason for creating BIRD197.3. Arpad did. Arpad took the AR to send this draft_1 of BIRD197.3 to the ATM list for further review. C_comp related ibischk bug #203: Bob shared the bug report for bug #203 and noted that the parser does not complain if C_comp_pullup or C_comp_pulldown are specified for an Input model. He noted that it was being considered as an enhancement to add a warning, or caution or note. Arpad noted that there had also been discussion of a possible technical issue to address in the spec. Bob said the broader technical issue is that the spec allows any of the C_comp_pullup, C_comp_pulldown, C_comp_power_clamp and C_comp_gnd_clamp to be specified for an Input model. He noted that the spec also contains this sentence: "For this reason, the EDA tool should generate a circuit netlist so that, if defined, each of the C_comp_* capacitors are connected in parallel with their corresponding I-V tables, whether or not the I-V table exists." Bob said the discussion can turn to "which rail does it connect to." Arpad asked why any of this was a problem. Walter posed a question to try to clarify the discussion. If one has an Input model with Power Clamp and Ground Clamp I/V tables and only [Voltage Range] specified, and all 4 C_comp_xxx values are specified as 1pF, how much capacitance should be in the simulation? Should the simulation have 1pF between signal and gnd, and 1pF between signal and the positive rail, or should it have 2pF between signal and gnd, and 2pF between signal and the positive rail? Bob said you should have a total of 4pF, 2pF between signal and gnd and 2pF between signal and the positive rail. Arpad noted the example of an FPGA, for which the user could configure a standard I/O cell into an Input. They would tie-off the pullup and pulldown transistors so they don't drive the circuit, but the devices are still there and you would still want to consider their capacitances. So, he saw no issue with providing all 4 C_comp_xxx values even though the buffer is an Input. He noted there could be an issue figuring out where to connect them if only [Voltage Range] were specified. Arpad posed another question. In the context of BIRD189 we have the buffer terminals defined in the syntax. What if the BIRD189 package model used all four rail terminal names (Pullup_reference, etc.), but the [Model] for that buffer only has [Voltage Range], what do you do then? Bob said you collapse them into the same node (pullup and power clamp terminals are the same, and pulldown and ground clamp terminals are the same). He said the way [Voltage Range] is intended to work is that it defines the value if any or all of the 4 *_reference keywords are missing. He noted that in practice terminal connections to real buffers rarely have separate terminals for pullup and power clamp (or pulldown and ground clamp). Walter noted that his interpretation was that an Input doesn't have 4 terminals, so he still didn't know how to connect capacitances in his example. He said he thought C_comp_pullup or C_comp_pulldown on an Input should generate a parser warning stating that those capacitances would be ignored. Arpad disagreed and referred to his FPGA example. Walter then said we need to clarify the spec because it's unclear. Radek suggested it would be better to clearly state that C_comp_pullup and C_comp_pulldown are considered even for an Input model. Otherwise he said we could get into trouble with I/O buffers depending on their state. Bob agreed and said that we never intended for an I/O buffer to ever switch off any of the C_comp_xxx paths. So, we expect them there regardless of the state of the buffer. Arpad asked what the immediate need is with respect to bug #203. Bob said the immediate goal was to classify the bug and decide if it requires a warning, or a caution, or a note. Walter said that if the interpretation is that they are always being used, then there shouldn't be any warning/caution/note at all. Bob said that we needed to clarify this in the spec and mention that all 4 C_comp_xxx values are always considered. Walter said that would be fine, and then this bug would be resolved as "no plans to fix." Arpad noted that he felt #203 was not a bug at all. Even with the current language in the spec there's nothing that says it's illegal to have C_comp_pullup or C_comp_pulldown in an Input model. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Arpad to send draft_1 of BIRD197.3 to the ATM list. ------------- Next meeting: 16 April 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives